Thanks for writing this up as a pull request -- righteous and nicely OOP-y. I'll try to grab a chance to review it soon.

@gigamonkey I don't have anything constructive to add, just wanted to say - really cool refactoring! Nicely done! :)

Jeremy, any chance this is actually going to get folded in?

This refactor is pretty cool - @jashkenas thoughts?

Whoops -- sorry, I had "[backbone]" tickets filtering out of the inbox for a couple of months there. It'll be time to come back around crank through some of these soon.

I'm afraid this may not apply after the changes to Model#set. :(

Well, it's good to merge now and it's only been sitting around for 2 months. :-(

@gigamonkey to be fair, it's typically better to bring up an issue first and then submit a pull request so theres no wasted efforts. jQuery encourages this so that people don't feel bad if ideas are turned down after they put significant time into a pull request.

Sure. I mentioned it to Jeremy before I started. And I'm cool with whatever you guys want to do. But if some other change was already in progress when I submitted my PR it would have been cool for someone to say, "Hey check this other upcoming change out and see if you can work with it." And if the other change came after mine, it'd have been nice if either mine had already been merged or if the other author had been told about my change.

Sorry about that @gigamonkey - I think your request came in just after the decision was made to completely rewrite set and strip out queued changes entirely, and the pull request was more directed at/responded to by Jeremy, so I figured it'd be in his court to take a look through.

I think @tgriesser's assessment is correct, but I'm sorry you spent time on this without being informed. We're attempting to address some of these organizational failings by using milestones to track features/fixes that are currently being worked on.

I have to apologize for dropping the ball on this -- the fault is entirely mine for "commissioning" it at a poor time.

That said, I think there are a couple of issues with implementing this particular direction:

• Ideally, we wouldn't introduce a new class that exists just to namespace some of the internal Model implementation. As the ChangeTracker is only ever instantiated within the Model constructor, it feels like it should simply be methods directly on the model itself.
• That unset change is righteous -- you have a great point about the JSON, and we should definitely do that.
• The model.changed property should stick around. It's useful, and is an intentionally-exposed part of the internals much like model.attributes is, or even model.id. Read-only reference properties.

So, closing, but thanks much!